fix(har): do not report zero sizes for bodies that were never read - #42371

Rationale

A redirect or basic-auth retry hop made through APIRequestContext is destroyed before its response
body is read (server/fetch.ts:496 and :507), so event.body is undefined when the tracer sees
it. The tracer turned that into a concrete zero:

this._storeResponseContent(event.body, content, 'other');   // sets content.size = 0 when undefined
if (!this._options.omitSizes)
  harEntry.response.bodySize = event.body?.length ?? 0;

The resulting entry contradicts itself. Recording a 302 that carries a 40 byte body produces:

HAR /redirect-me  status=302  bodySize=0  contentSize=0  contentLengthHeader=40

Content-Length: 40 sits in the entry's own headers next to bodySize: 0, which asserts the server
sent nothing. HAR 1.2 uses -1 for a size that is not available, and both fields already start at
-1.

The browser path in this same file already does the right thing: it only calls
_storeResponseContent inside response.internalBody().then(buffer => ...), so when the body cannot
be read the -1 survives. The two paths disagreed about the identical "body never captured" case.

Recording the sizes only when a body was actually captured makes the undefined-buffer branch of
_storeResponseContent unreachable, so that branch is deleted and the parameter stops being
optional. Net effect is fewer lines than before. An empty body is still recorded as 0, since an
empty Buffer is truthy and genuinely means zero bytes.

Test

should include redirects from API request already existed but only asserted the URLs and that
timings is defined, so nothing pinned the sizes. Two assertions go there rather than into a new
test. On current main they fail with Expected: -1, Received: 0.

Green: har.spec.ts 64 passed, global-fetch.spec.ts + browsercontext-fetch.spec.ts 192 passed,
flint clean.

Fixes #42370

the judgement call I am least sure of is whether anyone depends on the current 0, given how long
it has been that way. I checked it against the HAR 1.2 wording and against your own browser-side
handling rather than going on instinct, but you will know the compatibility risk better than I do.
freshman in college, happy to be told this is not worth changing :)